自动化测试上，你曾背弃诺言？

二十多年来，软件测试工具供应商一直在诱惑企业实现测试自动化。然而，事实上大多数公司从来没有能够实现他们的自动化计划所期望的业务成果。最近的研究报告显示，测试自动化率平均为20％左右，敏捷采用者为26-30％。

 （译者注：作者没给出具体的数据引用，我这里给出来源于State of testing 2017 final report 和State of Testing Survey Results- 2017的数据，从数据显示自动化测试整体不乐观，只有23%的企业自动化测试做得比较好，即自动化率超过一半，或者说，绝大部分测试已被自动化的公司达到32%，见下面两张图。两份结果不一致，但自动化测试做得好的，都没有超过三分之一）

我认为，这些令人沮丧的自动化结果有几个因素...

1.  传统的软件测试平台是旧时代的产物

目前最常用的软件测试工具是基于老的技术而构建的，但企业架构多年来一直在不断演化与发展。开发不再按季度发布周期来构建C/S桌面应用程序——每次发布之前都有一个月的测试窗口（译者注：这样长的时间窗口没有了，迫切需要极限测试、精确测试、高速的自动化测试）。

有了测试自动化工具（如Mercury，HP，Micro Focus，Segue，Borland和IBM）之后，几乎一切都已经发生了变化。将新功能装入已有的旧平台中，与那些基于新需求的原生解决方案是迥然不同的。

2. 传统的基于脚本的测试很难维护

当开发人员正在积极地开发应用程序时，脚本很难维护。应用程序迭代演化的频率越来越快，脚本保持同步就越来越困难。团队经常处在“创建新测试（脚本）速度比更新已有测试（脚本）更快”的境界。这导致一个更加笨重的测试套件，仍然（最终）产生令人沮丧的、大量的错误，因为应用程序不可避免地继续改变。维护挑战的加剧是脚本与代码一样容易受到缺陷的影响，并且脚本中的缺陷可能会导致误报和/或中断测试的执行。

误报率、脚本错误和膨胀的测试套件等一同造成的负担，很少有QA小组可以克服。这是一个永远不能完成的任务（Sisyphean effort ）——只有巨石不断增长、且越来越大。

（译者注：当进行大量的测试，如一个build要运行几万、十几万或更多测试时，误报率和错误带来的问题相当严重，Google都曾经被困扰过，后来专门研究了一种机制来解决这个问题。看一下Google的数据和下面这张图就更有体会：

• 15,000 developers run 120 million tests per day 

• 20+ code changes/minute – 50% code change/month 

• 5,500+ submissions/day – 120 million tests per day

• 80,000 builds per day – 20 million builds per year

）

3. 软件架构已经改变

软件架构发生了巨大变化，与现代企业应用相关的技术组合已经迅速扩展。随着我们转向云计算、云服务和微服务，我们正在努力迁移，远离大型机和C/S架构。这产生了两个明显的挑战：

• 测试这些技术需要高度的技术专长/专业化或高水平的业务抽象，允许测试人员在不涉及底层技术细节的情况下进行测试。

• 应用程序的不同部分正在以不同的速度发展，从而导致开发节奏不匹配。

4.  软件开发流程发生了变化

虽然今天大多数企业仍然拥有一些瀑布流程，但是，“交付的东西越来越小、迭代越来越快”是不可抗拒的发展趋势。我们已经从季度发布转为每周一次或每日一次 —— 甚至像这种特别的实例：亚马逊每11.6秒发布一次新的代码。发布周期的这种极端压缩对测试来说是一场灾难——特别是当大多数测试人员必须等待几天或几周才能使用合适的测试环境和测试数据。（译者注：今天有虚拟技术、Docker技术，还有测试数据自动生成智能／模糊工具等，情况不会那么糟糕）

5.  质量的责任发生了变化

为了响应更快的发布周期的需求，人们推崇 “测试左移”。创建代码的开发人员对质量承担更多的责任，因为他们的任务及时达到“完成的标准（DoD）”变得非常迫切。然而，对于从事复杂应用的大型企业，开发人员主导的测试主要集中在非常窄的、一小部分代码和组件上。开发人员通常缺乏测试能力和时间，完成现实中端到端业务交易的测试。虽然质量的职责已经向左移动，但是植根于瀑布过程的遗留依旧有明显的“朝右”偏见。这使得难以混合这两种方法。

6.  开源测试工具已经改变了行业

像Selenium和SoapUI等开源软件测试工具的兴起，已经产生了积极和消极的影响。传统上，开源测试工具像激光那样——专注于为单个用户解决一个非常具体的特定问题。例如，Selenium已经成为极受欢迎的、基于脚本的Web UI测试工具。虽然Selenium提供了速度和灵活性，但它不支持跨越应用程序、API、数据库、移动UI、主机应用等端到端的测试。毫无疑问，今天的大多数企业应用程序都肯定有Web UI的测试。然而，在大型企业中，Web UI仅仅是端到端业务流程的许多元素之一。同样的限制（问题）适用于SoapUI和API测试。

那么现在怎么办？

软件测试必须改变。 昨天的ALM工具无法应对今天的软件测试挑战。随着扩展到所有行业领域的DevOps、持续交付和敏捷等突破性的创新，软件测试成为数据驱动软件发布决策的核心。SDLC成熟度的新浪潮需要组织来改造过时的测试过程和工具。这意味着组织必须拥有能够进行持续测试的技术，否则创新的想法只会止步于昨天的重量级测试工具。